The present invention relates in general to data processing systems, and more particularly, to a system and method for Lightweight Directory Access Protocol (LDAP) client database access with backoff capability.
Information describing the various users, applications, files, printers and other resources accessible from a network is often collected into a special database, sometimes called a directory. As the number of different networks and applications has grown, the number of specialized directories of information has also grown, resulting in islands of information that cannot be shared and are difficult to maintain.
The Lightweight Directory Access Protocol (LDAP) is an open directory standard that has evolved to meet these needs. LDAP defines a standard method for accessing and updating information in a directory. LDAP is gaining wide acceptance as the directory access method of the Internet and is therefore becoming strategic within corporate intranets.
A directory is a specialized database, also called a data repository, that stores typed and ordered information about objects. Directories allow users or applications to find resources that have the characteristics needed for a particular task. A directory has characteristics that sets it apart from general purpose relational databases. One special characteristic of directories is that they are accessed (read or searched) much more often than they are updated (written). Because directories must be able to support high volumes of read requests, they are typically optimized for read access. Write access might be limited to system administrators or to the owner of each piece of information.
Another important difference between a directory and a general-purpose database is in the way information can be accessed. Most databases support a standardized, very powerful access method called Structured Query Language (SQL). SQL allows complex update and query functions at the cost of program size and application complexity. LDAP directories, on the other hand, use a simplified and optimized access protocol that can be used in relatively simple applications.
Directories are usually accessed using the client/server model of communication. An application that wants to read or write information in a directory does not access the directory directly. Instead, it has the function for application programming interface (API) that causes a message to be sent to another process. The second process accesses the information in the directory on the path of the requesting application. The results of the read or write operation are then returned to the requesting application. The request is performed by the directory client, and a process that looks up information in the directory is called the directory server. The format and content of the messages exchanged between client and server must adhere to an agreed upon protocol. LDAP defines a message protocol used by directory clients and directory servers. There is also an associated LDAP API for the C language and ways to access LDAP from within a Java application. The client is not dependent upon a particular implementation of the server, and the server can implement the directory however it chooses.
The directory itself can be centralized or distributed. If a directory is centralized, there is one directory server that provides access to the directory. If the directory is distributed, there is more than one server that provides access to the directory. When a directory is distributed, the information stored in the directory can be partitioned or replicated. When information is partitioned, each directory server stores a unique and non-overlapping subset of the information. That is, each directory entry is stored by one and only one server. When information is replicated, the same directory entry is stored by more than one server. In a distributed directory, some information may be partitioned, and some information may be replicated. The three xe2x80x9cdimensionsxe2x80x9d of a directory: scope of information, location of clients, and distribution of servers are independent of each other.
LDAP was developed as a lightweight alternative to the directory access protocol (DAP) which is used by the Internet Engineering Task Force (IETF) X.500 standard created in 1988. LDAP requires the lighter weight and more popular TCP/IP protocol stack rather than the OSI protocol stack. LDAP defines a communication protocol. That is, it defines the transport and format messages used by a client to access data in an X.500-like directory. LDAP does not define the directory service itself.
A common directory infrastructure encourages new uses. The Directory Enabled Networks (DEN) Initiative is a proposal to allow information about network configuration, protocol information, router and switch characteristics, Virtual Private Networks (VPNs), etc., to be stored in an LDAP directory. The availability of this information in a common format for many equipment vendors allows the intelligent management and provisioning of network resources. Within the networking industry, DEN is currently viewed as a key piece to building intelligent networks, where products from multiple vendors can store and retrieve topology and configuration information from an LDAP server. Through DEN, these devices and services use LDAP to implement authentication and policy services, allowing guaranteed end-to-end quality of service (QOS) and other features.
LDAP defines the content of messages exchanged between an LDAP client and an LDAP server. The messages specify the operations requested by the client (search, modify, delete, etc.), the responses from the server, and the format of data carried in the messages. LDAP messages are carried over TCP/IP, a connection-oriented protocol; so that there are also operations to establish and disconnect a session between the client and server.
The general interaction between an LDAP client and an LDAP server takes the following form:
1. The client establishes a session with an LDAP server. This is known as binding to the server.
2. The client then performs operations on directory data. LDAP offers both read and update capabilities. This allows directory information to be managed as well as queried.
3. When the client is finished making requests, it closes the session with the server. This is also known as unbinding.
A directory entry usually describes an object such as a person, a printer, a server, etc. Each entry has a name called a distinguished name (DN) that uniquely identifies it. The DN consists of a sequence of parts called relative distinguished names (RDNs), much like a file name consists of a path of directory names in many operating systems such as UNIX and WINDOWS. The entries are arranged into a hierarchical tree-like structure based on their distinguished names. This tree of directory entries is called the Directory Information Tree (DIT).
Each entry contains one or more attributes that describe the entry. Each attribute has a type and a value. A directory entry describes an object. An object class is a general description, sometimes called a template, of an object as opposed to the description of a particular object. The object classes that a directory server can store and the attributes they contain are described by a schema. Schema define the object classes that are allowed, the attributes that they must contain, the attributes that are optional, and the syntax of each attribute. One or more schemas may be supported by the client and server.
A VPN policy configuration application is used to define VPN policies between pairs of VPN devices. The VPN policies are stored in an LDAP server and subsequently downloaded to the VPN devices during initialization or upon request from a VPN network management application.
The VPN devices (LDAP clients) may access the LDAP server to retrieve their policies at any time due to initial startup or administrative request. The VPN policy configuration application (LDAP client) may access the LDAP server to alter one or more policy definitions at any time. Since the LDAP protocol currently has no locking mechanism, a variety of problems may result when one or more clients attempt to access the LDAP server for information while another client is in the process of altering the information contained in the LDAP server.
It is therefore an object of the present invention to provide a mechanism to enable LDAP clients to read information from an LDAP server directory while another LDAP client is attempting to update information.
The foregoing objective is achieved by maintaining a current tree of directory information that is used by LDAP clients to retrieve configuration information. The current tree is never altered. Whenever an LDAP client wants to update configuration information, i.e., add, change or delete, a new directory tree of configuration information is created. This creation may be done by cloning the parent tree, cloning a previous tree, or by starting from scratch. When the updating LDAP client is finished building a new directory tree of configuration information, the path definition of the information retrieval LDAP client is set to the new information tree and the information retrieval LDAP client is requested to re-read the LDAP directory information containing the new policies. If the new directory tree of policy configuration information is found to be defective, the path definition of the information retrieval LDAP client is reset to the original information tree and the information retrieval LDAP client is requested to re-read the LDAP information, in this case, the original policies.